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Abstract 

Storagejamming  can  degrade  real -world  activi¬ 
ties  that  share  stored  data.  Storage  jamming  is 
not  prevented  by  access  controls  or  cryptographic 
techniques.  Verification  to  rule  out  storage  j  am¬ 
ming  I ogi c  is  i mpracti cal  for  sh ri n k-  wrapped 
softwareor  low-cost  custom  applications.  Detec¬ 
tion  mechanisms  do  offer  more  promise.  In  this 
paper,  we  model  storagejamming  and  a  detection 
mechani  sm,  usi  ng  Unity  I  ogi  c.  We  find  that  U  ni  ty 
logic,  in  conjunction  with  some  high -I e/el  opera¬ 
tors,  models  storage  jamming  in  a  natural  way 
and  allows  us  to  reason  about  susceptibility,  rate 
of  jamming,  and  impact  on  persistent  values. 

1.  Introduction 

Storage  jamming  [10]  is  malicious  modification 
of  stored  data,  for  the  purpose  of  degrading  real- 
world  operations  that  depend  on  the  correctness 
of  the  data.  The  jammer's  objective  is  to  reduce 
the  quality  of  stored  data  below  a  certain  level, 
without  being  detected.  We  assume  the  person 
initiating  the  malicious  modification  (frequently 
via  a  Trojan  horse)  does  not  receive  any  direct 
benefit,  financial  or  otherwise,  but  rather  is  mo¬ 
tivated  by  more  indirect  goals  such  as  improving 
the  competitive  position  of  his  or  her  own  organi¬ 
zation.  We  also  assume  that  the  attacks  are  not 
made  across  access  control  boundaries.  The  tar¬ 
get  data  need  not  be  data  stored  by  a  database 
system,  it  can  be  any  values  stored  for  future  ref¬ 
erence.  We  call  the  values  introduced  i  nto  stor¬ 
age  by  the  jammer  bogus  values.  We  cal  I  the 
values  we  mean  to  store  authentic  values.  If  a 
storage  object  contains  a  bogus  value,  we  say 
that  the  storage  object  has  been  jammed. 

I  n  the  past,  the  most  likely  motive  for  attacks 
that  modify  data  would  have  been  financial  gain. 


The  problem  of  fraud  has  been  addressed  by 
Clark  and  Wilson  [3],  by  Sandhu  and  J  ajodia 
[15],  and  by  others  [8,  12].  However,  changes  in 
technology  have  made  many  organizations  de¬ 
pendent  on  information  systems.  It  is  now  possi¬ 
ble  to  disrupt  or  degrade  their  operations  by 
interfering  with  their  supporting  information 
systems  [4], 

There  are  several  security-oriented  data  integri¬ 
ty  approaches  that  were  designed  for  other  pur¬ 
poses  but  also  may  hinder  jamming  attacks  [10]. 
The  Clark-Wi Ison  model  offers  little  protection 
because  the  jammer  can  construct  bogus  values 
that  satisfy  its  constrai  nts.  The  assured  pipeline 
of  Boebert  and  Kain  [1]  also  appears  promising, 
but  really  does  not  work  for  data  that  is  not  im¬ 
mediately  sent  to  output.  Sandhu's  transaction 
control  expressions  [14]  do  better  because  a  hu¬ 
man  is  required  to  validate  changes,  and  be¬ 
cause  updates  can  be  forced  to  go  through 
multiple  integrity  domains  with  separate 
checks.  H  owever,  to  be  ful ly  effective  agai nst 
storage  jamming,  transaction  control  expres¬ 
sions  require  partial  correctness1  of  the  majority 
of  the  software.  Wiseman's  extended  trusted  [18, 
19]  path  does  prevent  storagejamming,  but  also 
requires  partial  correctness  of  every  piece  of  soft¬ 
ware  that  accesses  data,  from  keyboard  to  dis¬ 
play.  While  possible  in  principle,  these  last  two 
approaches  are  unworkable  storage  jamming  de¬ 
fenses  in  a  world  of  shrink-wrapped  general-pur- 


1.  We  use  the  term  in  its  broadest  sense:  that 
something  much  more  rigorous  and  resource 
consuming  than  conventional  software  engineer¬ 
ing  is  required.  Because  it  is  so  easily  detected, 
we  consider  nontermination  to  be  an  ineffective 
storage  jamming  technique. 
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pose  products  and  rapidly-developed  low-cost 
custom  applications.  Sincejamming  can  occur 
upstream  of  any  encryption  process,  direct  appli¬ 
cation  of  cryptographic  techniques  does  not  seem 
to  be  workable  either. 

The  most  promising  defense  against  jamming  is 
detection  [10].  Even  then,  the  detection  mecha¬ 
nisms  must  be  suited  to  the  problem;  the  various 
intrusion  detection  approaches  will  not  work  be¬ 
cause  the  necessary  audit  and  reduction  would 
be  computationally  infeasible,  if  even  decidable. 

I  nstead,  we  propose  detection  objects  as  a  suit¬ 
able  defensive  mechanism. 

This  paper  presents  our  work  to  date  on  formu¬ 
lating  a  satisfactory  model  of  storage  jamming. 
First  we  provide  an  example  of  jamming,  then 
we  look  at  the  criteria  a  good  model  of  storage 
jamming  should  satisfy.  We  then  present  our 
current  model  and  use  it  to  describe  an  example. 
Then  we  show  how  to  add  a  defense  to  our  exam- 
pi  e.  We  conclude  by  discussing  how  our  model 
meets  our  criteria. 

At  this  point,  an  example  will  clarify  our  presen¬ 
tation.  Suppose  we  have  a  simple  word  processor 
with  three  commands:  ne/v,  to  create  a  new  docu¬ 
ment,  edit,  to  enter  or  change  text  and  figures, 
and  delete,  to  remove  a  document  and  return  its 
associated  file  handle  to  the  file  system.  The 
jammer  is  attached  to  the  word  processor.  F  ol- 
lowing  certain  edit  operations,  it  overwrites  the 
authentic  file  with  an  earlier  version,  thus  de¬ 
stroying  the  results  of  any  intervening  sessions. 
(This  kind  of  repeat-back  attack  cannot  be  de¬ 
tected  with  conventional  or  cryptographic  se¬ 
quence  numbers  because  the  malicious  software 
is  not  a  third  party.  Since  the  malicious  software 
is  part  of  the  program  that  originates  authentic 
files,  the  malicious  software  can  obtain  an  arbi¬ 
trary  number  of  new,  valid  sequence  numbers  to 
associate  with  earlier  versions  of  word  process¬ 
ing  documents.)  Thejammer  is  not  intended  to 
destroy  all  editing  sessions,  only  a  small  fraction 
of  them.  Thejammer  does  not  attempt  to  write 
bogus  values  in  any  files  outside  its  current  ac¬ 
cess  control  domain. 


2.  Criteria  for  Modeling 

We  want  to  use  our  model  to  describe  and  predict 
threethings:  the  strategies  that  might  be  em¬ 
ployed  by  specific  jammers,  the  susceptibility  of 
target  systems,  and  the  effectiveness  of  protec¬ 
tion  mechanisms  we  might  adopt. 

2.1.  Strategies  for  thej  ammer 

It  is  helpful  to  characterize  storage  jamming  in 
terms  of  the  possible  strategies.  There  are  many 
possible  characteristics,  we  consider  eight  here 
that  are  applicable  to  models: 

Persistence  Of  Bogus  Values:  The  unauthorized 
changes  can  be  persistent  or  thejammer  can  re¬ 
store  the  changed  values  after  an  arbitrary 
length  of  time.  One  useful  variation  of  this, 
shown  in  our  example,  is  to  save  deleted  objects 
or  values  and  reintroduce  them  at  a  later  time. 
Temporary  bogus  values  would  be  harder  to  de¬ 
tect  than  persistent  ones  but  may  still  be  read  by 
critical  applications  or  system  programs. 

Security  Attributes  OfTheJ  amming  Program: 
The  jamming  may  be  done  by  an  authorized  pro¬ 
gram  or  by  an  unauthorized  program.  If  it  is 
done  by  an  authorized  program  it  may  be  done 
as  part  of  an  authorized  invocation,  i.e.,  the  pro¬ 
gram  simply  writes  incorrect  values,  or  thejam¬ 
mer  may  be  able  to  cause  an  unauthorized 
invocation  of  a  legitimate  application. 

Means  Of  Choosing  Bogus  Values:  Thejammer 
can  adopt  a  number  of  basic  algorithms  for  gen¬ 
erating  the  data  to  write.  For  example,  the  bogus 
values  can  be  chosen  arbitrarily,  randomly,  by 
interpolation,  by  replay,  or  by  permutation.  Arbi¬ 
trary  choices  may  be  easier  to  detect,  but  can  be 
performed  by  small  programs  that  may  be  easier 
to  insert  into  a  system. 

Means  of  Choosing  Target  Storage  Objects:  The 
jammer  can  select  targets  randomly,  via  some  se¬ 
lection  criteria,  or  by  simply  piggybacking  on  an 
application  program.  The  latter  approach  lets 
the  application  chose  the  target  for  thejammer. 
As  we  said  in  the  introduction,  the  data  can  be 
application  data,  linkage  data,  metadata,  or  sys¬ 
tem  data.  Others  important  target  selection 
characteristics  are  the  level  of  abstraction  and 
target  granularity.  For  example,  the  units  of  tar- 
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get  data  (storage  objects)  could  be  data  in  a  rela¬ 
tional  database  or  they  could  be  disk  blocks  in 
the  nodes  of  a  B+tree.  Thejammer  could  target 
entire  sets  or  lists  of  data,  or  select  components 
of  a  single  storage  object. 

Rate  Of  Change  I  n  Target  Data:  If  thereare 
many  updates  to  the  data,  then  jamming  may  be 
easier.  There  will  be  more  opportunities  and 
more  checks  will  be  required  to  detect  the  jam¬ 
ming. 

RateOfJ  amming:  The  rate  at  which  bogus 
changes  are  made  is  significant.  A  jammer  may 
be  designed  tojam  as  fast  as  possible  without  be¬ 
ing  detected,  with  the  expectation  that  thejam¬ 
mer  will  only  be  triggered  at  a  critical  moment. 
Alternatively,  thejammer  may  run  continuously 
and  make  changes  infrequently. 

Extent  Of  J  amming:  A  slow  jammer  can  still  do 
much  damage  by  using  a  cumulative  strategy  of 
jamming  slowly  but  widely,  i.e.  ultimately 
change  every  value  stored  in  a  system.  This  type 
of  jamming  is  called  barragejamming.  On  the 
other  hand,  a  jammer  can  hope  to  escape  detec¬ 
tion  but  still  disrupt  operations  by  only  modify¬ 
ing  a  critical  subset  of  the  stored  data.  This  kind 
of  jamming  is  called  spot  jamming. 

Adaptability  Of  The)  ammer:  An  enemy  may 
hope  to  do  more  damage  by  having  the  jamming 
software  change  its  strategy.  This  may  be  a  sim¬ 
ple  adaptation,  such  as  changing  the  constraints 
that  are  checked  when  generating  bogus  values. 
The  adaptation  may  be  more  complex;  for  exam- 
plethejammer  might  try  adapt  to  detection 
mechanisms  that  might  be  present.  On  defense, 
we  may  have  to  prevent  thejammer  from  read- 
ing  the  data  or  code  of  a  detection  mechanism,  in 
order  to  frustrate  this  adaptability. 

2.2.  Vulnerability  to  J  amming 

A  system’s  vulnerability  to  electronic  warfare  is 
often  characterized  in  terms  of  interceptibility, 
accessibility,  and  susceptibility  [17];  this  seems 
appropriate  for  storage  jamming  as  well,  inter¬ 
cept'!  bi I ityls  a  measureof  the  ease  with  which  an 
enemy  can  determine  the  existence,  function, 
and  location  of  a  system.  Accessibility  is  a  mea¬ 
sure  of  the  ease  with  which  an  enemy  can  reach 
a  system  with  an  effective  electronic  warfare  at¬ 


tack.  Susceptibility  is  a  measure  of  system  prop¬ 
erties  that  determines  the  effect  of  various 
attacks  on  the  system.  I  n  our  models  we  are  pri¬ 
marily  concerned  with  susceptibility. 

Performance  criteria  for  measuring  susceptibili¬ 
ty  can  include 

1.  mission  failurerate.  therateat  which 
activities  supported  by  the  system 
fail, 

2.  query  error  rate,  the  rate  at  which 
queries  are  not  processed  according 
to  the  system  data  model,  database 
design,  and  the  authentic  history  of 
the  system, 

3.  record  error  rate,  the  rate  at  which  er¬ 
roneous  records,  object  instances, 
etc.,  occur  in  storage, 

4.  field  error  rate,  the  rate  at  which  er¬ 
roneous  fields  of  a  record,  attributes 
of  an  object,  etc.,  occur  in  storage,  and 

5.  bit  error  rate,  the  rate  at  which  erro¬ 
neous  bits  occur  in  the  representa¬ 
tion  of  data. 

We  want  our  model  to  be  able  to  predict  vulnera¬ 
bility  criteria  two  through  five.  Since  prediction 
of  criterion  one  measurements  requires  subject 
matter  expertise  from  the  application  domain 
and  heuristics  taken  from  the  realm  of  artificial 
intelligence,  mission  failure  rate  is  outside  the 
scope  of  this  paper. 

2.3.  Effectiveness  of  Protection  Mecha¬ 
nisms 

Our  third  criterion  for  a  model  is  ability  to  de¬ 
scribe  and  predict  the  effectiveness  of  defenses 
we  might  employ.  The  most  promising  approach 
is  detection  of  jamming  [10],  If  the  jamming  is 
detected,  we  may  often  assume  that  it  will  cease 
to  be  effective.  So  a  system  that  allows  easy  de¬ 
tection  of  jamming  may  not  be  very  susceptible 
to  it,  even  though  the  system  has  no  way  of  pre¬ 
venting  or  tolerating  the  jamming  that  may  oc¬ 
cur  before  detection.  Thus  we  want  to  be  able  to 
describe  detection  of  jamming,  both  in  possibilis- 
tic  terms  and  in  probabilistic  terms  (to  construct 
statistics  for  rate  and  extent). 
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3.  Modeling 

The  critical  factor  in  storage  jamming  is  the  as¬ 
signment  of  values  to  data  objects:  which  storage 
objects  are  changed  and  are  the  changes  authen¬ 
tic  or  bogus?  For  this  reason,  the  operations  and 
structure  of  our  model  are  based  on  assignment 
to  variables. 

We  adopt  the  U  nity  [2]  model  of  computation  as 
our  starting  point.  Unity  programs  have  assign¬ 
ments  but  no  control  flow.  The  control  flow  is  re¬ 
placed  by  unbounded  nondeterministic  iteration. 
Unity  defines  both  a  notation  for  writing  concur¬ 
rent  programs,  and  a  logic  for  reasoning  about 
computations  (executions  of  those  programs). 
Besides  its  freedom  from  flow-control,  U  nity  has 
two  important  characteristics: 

U  nity  provides  predicates  for  specifications 
and  proof  rules  to  derive  specifications 
directly  from  the  program  text.  This  type 
of  proof  strategy  is  often  clearer  and  more 
succinct  than  an  argument  about  a 
program's  operational  behavior. 

Unity  separates  the  concerns  of  algorithm 
and  architecture.  It  defines  a  general 
semantics  for  concurrent  programs  and 
encourages  the  refinement  of  architecture 
independent  programs  to  architecture 
specific  ones. 

As  an  example  of  the  Unity  notation,  consider 
the  foil  owing  program  which  sorts  an  array  of  n 
elementsX[l]...X[n]  into  non-decreasing  order. 
(This  introduction  to  Unity  is  from  Goldschlag 
[6].)  The  program  consists  of  an  assign  section, 
lines  2-4.  Unity  programs  are  organized  into  sev¬ 
eral  sections:  declare,  initially,  always,  as¬ 
sign.  The  assign  section  contains  all  of  the 
assignments.  We  shall  see  examples  of  the  other 
sections  as  they  become  necessary. 

This  program  contains  n(n- 1)/2  statements,  each 
of  which  swaps  an  out-of-order  pair  of  array  ele¬ 
ments.  Unity  uses  the  interleaved  model  of  con¬ 
currency,  so  the  execution  of  this  program  is  as 
follows:  Some  statement  is  chosen.  Thecondition 


(guard)  fol  lowi  ng  the  if  is  evaluated.  I  f  the  condi¬ 
tion  is  false,  the  statement’s  execution  is  equiva¬ 
lent  to  a  skip  statement.  If  thecondition  is  true, 
the  statement  is  executed,  and  the  out-of-order 
pair  is  swapped.  Another  statement  is  then  cho¬ 
sen,  and  the  process  is  repeated.  The  only  re¬ 
striction  on  the  scheduling  of  statements  is  a 
fairness  restriction,  which  requires  that  every 
statement  be  scheduled  infinitely  often.  Al¬ 
though  execution  never  terminates,  a  fixed  point 
may  be  reached  when  all  statements  are  equiva¬ 
lent  to  skip's. 

To  demonstrate  the  correctness  of  this  program, 
we  must  first  present  the  specification.  We  will 
do  this  somewhat  informally.  The  specification  is 
broken  down  into  two  parts.  The  first  states  that 
the  final  array  is  a  permutation  of  the  original 
array.  This  is  a  consequence  of  the  fol  I  owing 
property:  the  bag  of  values  that  fills  the  array  X 
is  unchanged  throughout  the  computation.  This 
sort  of  property  is  an  invariant,  specified  as:  in¬ 
variant  bag(X)  =  K.  This  means,  roughly,  that  if 
the  bag  of  values  in  array  X  is  equal  to/C  before 
executing  any  statement  in  the  program,  then 
the  bag  of  values  in  that  array  is  unchanged  sub¬ 
sequent  to  executing  any  statement  in  the  pro¬ 
gram.  Si  nee  every  statement  at  most  swaps 
array  values  and  no  values  areever  lost,  this  in¬ 
variant  is  true. 

The  second  part  of  the  specification  states  that 
the  array  will  eventually  become  sorted.  This  is 
a  liveness  (or  a  progress)  property.  I  n  Unity,  this 
is  stated  by  true  leads-to  sorted(X).  The  val ue 
truesimply  states  that  there  are  no  precondi¬ 
tions  on  this  property.  To  prove  this  liveness 
property,  we  use  the  fol  I  owi  ng  measure:  I  magi  ne 
a  lexicographic  less  than  relation  on  n  elements. 

I  f  the  array  is  not  sorted,  then  every  statement 
in  the  program  either  modifies  the  array  to  one 
with  a  smaller  lexicographic  order,  or  does  not 
change  the  array  at  all.  Furthermore,  ifthear- 


1  program  prg 

2  assign 

3  <0  i,j  :  0</  <j  <n  ::X[/],  X\j]  :=X(/],X[/]  if  X\j]<X[i] 

4  > 

5  end  //  prg  // 
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ray  is  not  sorted,  some  statement  modifies  the 
array.  By  fairness,  the  array's  lexicographic  or¬ 
der  will  eventually  decrease.  The  fact  that  this 
lexicographic  order  decreases  may  be  repeatedly 
applied  by  induction,  toconcludethat  eventually 
the  array  becomes  sorted. 

The  Unity  logic  differs  from  other  temporal  logic 
proof  systems  for  reasoning  about  concurrency 
because  it  is  really  only  a  subset  of  temporal  log¬ 
ic.  Unity’s  specification  predicates  provide  a  sim¬ 
ple  and  powerful  vocabulary  to  specify  and 
reason  about  the  behavior  of  concurrent  pro¬ 
grams.  They  permit  the  specification  of  many 
temporal  properties  without  introducing  all  of 
temporal  logic.  However,  the  specification  predi¬ 
cates  i  nvar iant  and  leads-to  are  operators  that 
take  predicates  as  arguments,  and  are  not  quan¬ 
tifiers  like  V,  3,  or  temporal  logic's  always  or 
eventually.  This  means  that  these  operators  may 
not  be  nested,  and  that  U  nity  is  less  expressive 
than  full  first-order  temporal  logic.  Unity  pro¬ 
vides  proof  rules  for  taking  large  formal  proof 
steps,  and  is  (relatively)  complete,  even  though 
it  contains  fewer  proof  rules  than  other  temporal 


logics.  The  soundness  and  completeness  of  U  nity 
are  discussed  in  [5,9,11], 

To  see  how  we  use  U  nity  to  model  storage  jam¬ 
ming,  let  us  return  to  our  example  jammer,  now 
modeled  in  Unity  logic  as  program  wj.  We  begin 
by  descri  bi  ng  the  file  system  as  an  array  of  files 
and  the  user  input  as  a  tuple  that  contains  the 
intended  word-processor  operation  and  the  name 
of  its  operand.  The  define  section  is  a  natural 
extension  to  Unity  that  allows  us  to  define  new 
data  types  to  model  compl  ex  storage  structures. 

Now  that  we  have  established  the  structure  of 
the  data,  we  can  present  the  word  processor  it¬ 
self,  with  the  attached  jammer. 

We  model  the  jammer  and  the  word  processor  as 
a  concurrent  program  with  only  one  statement 
that  covers  lines  16  through  20.  This  one  state¬ 
ment  is  composed  of  three  assignment  state¬ 
ments  separated  by  the  concurrent  operator  ||, 
which  means  that  the  three  assignments  are  ex¬ 
ecuted  concurrently.  The  variables  that  are  be¬ 
ing  assigned  must  appear  only  once,  to  avoid 
conflicts.  The  new  values  of  these  variables  are 
computed  by  eval  uati  ng  the  expressi  ons  on  the 


1  program  wj 

2  define 

3  command  =  tuple  of  ( 

4  op  :  operation;  //  the  name  of  the  word  processor  operation  to  be  applied  to// 

5  file  :  int  //the  specified  file// 

6  ) 

7  declare 

8  f=array[0..  MAX]  of  filetype  //the  part  of  the  filesystem  that  is  accessibleto  us// 

9  t  =array[0..  MAX]  of  filetype  //simplistic  temporary  storage  for  the  jammer  // 

10  in:  command  //  the  command  i  nput  by  the  user  // 

11  initially 

12  t  =  f  //jammer  copies  the  initial  values  of  the  file  system// 

13  count  =  0  //jammer  initializes  its  counter  // 

14  i  n  =  E  M  PTY  //  word  processor  waits  for  user  i  nput  // 

15  assign 

16  f[i n.fil e],  count  :=  i n.op(f[i n.file]),  count +lif  count  <J  AM  a  in  ^  EMPTY 

17  ~  i n.op(f[i n.file]),  0  if  count  >J  AM  a  in. op  A  edit  a  in  =£  EMPTY 

18  ~  t[i n.file],  0  if  count  >J  AM  a  in. op  =  edit 

19  ||  in  :  =  EMPTY  ifin^EMPTY 

20  II  t  :=f  if  in  ^  EMPTY 

2  lend  //  wj  // 
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right  hand  sides  of  the  assignment  operator  first, 
and  then  doing  the  assignments.  The  first  as¬ 
signment  statement,  beginning  on  line  16,  has 
three  sets  of  expressions  controlled  by  guards 
separated  by  The  guard  that  is  true  defines 
which  set  of  expressions  is  evaluated.  At  most 
one  guard  may  be  true  at  a  ti  me.  I  f  no  guard  is 
true,  the  statement  is  equivalent  to  a  skip  state¬ 
ment. 

The  third  assignment  statement,  on  line  20,  cop¬ 
ies  the  array  f  to  array  t,  modeling  the  tempo¬ 
rary  storage  of  old  values  for  rewrite  attacks. 

For  simplicity,  we  do  not  test  individual  files  to 
see  if  they  have  changed.  The  second  assignment 
statement,  on  line  19,  makes  the  program  work 
in  lockstep  with  the  user:  it  "waits" for  a  com¬ 
mand,  performs  the  request  and  then  "waits"  for 
another  command.  We  say  "waits"  because,  in 
our  model  of  execution,  program  wj  could  be  cho¬ 
sen  to  run  an  arbitrary  number  of  times  before 
any  other  program  could  set  the  value  of  in  to 
some  nonempty  tuple.  Then  every  execution  of 
wj  would  be  equivalent  to  a  skip.  I  n  execution 
histories  where  in  is  set  to  something  other  than 
E  M  PTY,  then  wj  operates  on  a  file  once  for  each 
time/'n  is  set,  and  then  resets  it  to  EMPTY. 

We  call  this  jammer  a  counting  jammer  because 
it  uses  a  counter  to  control  its  operation,  rather 
than,  say,  a  random  number  generator.  We  de¬ 
signed  this  jammer  not  to  act  when  changes  to 
the  file  system  are  deletes  or  resets  because  we 
are  assuming,  on  the  part  of  the  adversary,  that 
restoring  deleted  or  empty  files  would  attract  too 
much  attention. 

A  proof  that  the  jammer  jams  is  simple.  We  want 
to  show  that,  if  the  trigger  condition  is  satisfied, 
line  18  of  program  wj  is  the  one  that  sets  the  val¬ 
ue  of  the  file  f[ in.  file],  using  a  value  from  array  t. 
The  trigger  condition  requires  that  some  opera¬ 
tion  whose  index  in  the  input  sequence  is  divisi¬ 
ble  by  J  AM+1  be  an  (edit,  Wn.file])  command. 
The  proof  itself  is  accomplished  by  superposi  ng  a 
variableXcto  count  the  number  of  times  a  bogus 
value  is  written.  I  nitiallyXcis  zero  and  we  show 
that  it  must  be  positive  if  the  trigger  condition  is 
satisfied.  We  superpose Xc  by  adding  a  line  ||  Xc 
:=Xc+l  if  count  >J  AM  a  in. op  -edit,  tothe 
one  statement  in  the  assign  section.  Since  the 


value  of  Xcis  not  read  by  any  part  of  the  original 
program,  this  superposed  variable  does  not 
change  the  behavior  of  the  original  program. 

We  also  want  to  be  able  to  reason  about  the  rate 
and  extent  of  the  jamming  by  program  wj.  To  do 
this  we  superpose  variable  Ycto  count  the  num¬ 
ber  of  times  an  edit  operation  is  input  just  when 
count>  J  AM.  Then  we  show  that  Yc=Xc  is  an  in¬ 
variant  of  program  wj.  Given  this  relationship, 
we  can  now  define  simple  random  variables  X 
and  Y  to  correspond  tothe  program  variables  Xc 
and  Yc.  Then  we  can  assign  a  distribution  (for 
example,  a  binomial  distribution)  to  Y,  allowing 
us  to  make  probability  statements  P{Y<k}=y, 
for  appropriate  values  of  k.  Since  Yc=Xc  is  an  in¬ 
variant,  we  can  say  that  random  variableX  has 
the  same  distribution  function  as  random  vari¬ 
able  Y. 

This  completes  our  discussion  of  modeling  jam¬ 
mers  and  their  targets.  The  next  step  is  to  ex¬ 
pand  our  example  to  show  how  we  model  a 
defensive  mechanism.  We  choose  to  model  a 
quarantine-subsystem  detection -object  defense 
[10].  A  detection  object  is  an  abstract  mechanism 
that  is  intended  to  detect  the  actions  of  mali¬ 
cious  software  that  jams  storage.  It  overcomes 
the  difficulty  of  checking  the  computation  per¬ 
formed  by  a  program,  by  always  being  in  a  pre¬ 
computed  (i.e.,  predictable)  state.  If  the 
detection  object  is  not  in  its  proper,  predicted 
state,  then  it  was  probably  modified  by  a  jam¬ 
mer.  We  call  the  storage  objects  that  are  intend¬ 
ed  to  store  legitimate  data,  i.e.  not  detection 
objects,  protected  storage  objects.  Protected  stor¬ 
age  objects  and  detection  objects  are  defined  in 
terms  of  jammers  that  might  target  them.  Detec¬ 
tion  objects  satisfy  two  properties 

1.  Detection  objects  are  indistinguish¬ 
able,  to  the  jammer,  from  their  corre¬ 
spond!  ng  protected  storage  objects, 
that  is,  they  satisfy  the  jammer 'star- 
get  selection  rules.  We  call  thiscondi- 
tion  indistinguishability. 

2.  The  only  legitimate  process  that 
modifies  detection  objects  is  the  jam¬ 
ming  detection  process.  We  cal  I  this 
condition  sensitivity. 
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A  quarantine  subsystem  detection  object  defense 
avoids  the  defensive  problem  of  distinguishing 
detection  objects  from  protected  storage  objects. 

I  n  a  quaranti  ne  subsystem  the  enti  re  subsystem 
contains  only  detection  objects,  thus  achieving 
complete  sensitivity.  An  examplewould  bea  fake 
user  implemented  by  a  workstation.  The  work¬ 
station  software  would  log  on,  create  new  direc¬ 
tories  and  files,  perform  word  processing  edits, 
etc. 

The  program  detector  is  our  model  of  a  quaran¬ 
tine  subsystem.  It  runs  interleaved  with  pro¬ 
gram  wj,  that  is,  wj  D  detector.  The  program  wj  0 
detector  is  equivalent  to  the  program  obtained  by 
appending  the  corresponding  sections  of  the  two 
programs,  with  the  interleaved  operator  0  be¬ 
tween  the  statements  of  the  assign  sections. 


tire  filesystem,  using  the  function  check.  (We 
check  the  enti  re  file  system  in  case  the  jammer 
attacks  a  file  other  than  the  current  operand.)  As 
it  repeats,  the  script  must  restore  the  file  system 
to  the  same  initial  state,  in  order  for  the  check¬ 
sums  to  work.  The  success  of  this  approach  re¬ 
quires  two  assumptions:  1)  that  we  had  a  good 
copy  of  the  word  processor  when  we  generated 
the  checksum  values  stored  in  array  ok,  and  2) 
that  function  check  has  the  property  that 
check{f1)^check{f2)  iff  It  would  be  difficult 
to  show  that  either  of  these  assumptions  were 
generally  true,  but  it  is  reasonable  to  assume 
that  we  can  approxi  mate  either  of  them  wel  I 
enough  for  practical  application.  I  n  some  cases 
that  we  do  not  have  room  to  descri  be,  we  can  use 
a  Byzantine  generals  protocol  on  scripts  and 
check  val  ues  to  ensure  that  we  are  usi  ng  a  good 


1  program  detector 

2  declare  local 

3  op  =array[0  ..  LASTSTATE]  of  operation// script  of  operations  to  perform// 

4  file  =array[0  ..  LASTSTATE]  of  int  //script  of  filenames  to  be  performed  upon // 

5  ok  =array[0..  LASTSTATE]  of  checksum// precomputed  checksums  for  script  states// 

6  var  state:  int 

7  var  alarm  :  Boolean 

8  function  check(var  f  :  array  of  filetype) :  checksum 

9  initially 

10  state  =  0 

11  alarm  =false 

12  <V  i  :  0  <  i  <  MAX  ::  f[i]  =  NEW  > 

13  assign 

14  in. op,  in.file,  state  :=  op[state],  file[state],  state+lif  state <  LASTSTATE  a  in  =EMPTY 

15  ~  optstate],  file[state],  0  if  state  >  LASTSTATE  a  in  =  EMPTY 

16  ||  alarm  :=check(f)  ^  ok[state]  if  alarm  =falseA  in  =EMPTY //latch  alarm// 

17end  //detector// 


Program  detector  shares  the  i/o  tuple  in  and  the 
filesystem  array  f  with  program  wj.  Detector  is 
designed  to  run  in  lock-step  synchronization 
with  the  jammer,  because  of  the  way  it  uses  the 
shared  variable  in;  the  detector  only  submits  a 
new  command  when  the  previous  one  has  been 
removed  and  carried  out.  Detector  submits  a  se¬ 
quence  of  commands  from  a  script  and  checks 
the  results  by  computing  a  checksum  on  the  en- 


copy  of  the  application  program  togeneratethe 
script. 

The  detector's  script  is  stored  in  two  arrays,  one 
a  list  of  operations  op  and  the  other  a  list  of  file¬ 
names  file.  J  ust  like  program  wj,  detector  is  a 
single  concurrent  assignment.  The  variablestate 
represents  the  state  of  the  detector  and  is  used 
to  i  ndex  both  the  scri  pt  and  the  checksums 
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stored  in  the  array  ok.  The  detector  cycles 
through  the  script,  checking  each  result  as  it 
goes.  We  have  attached  the  modifier  local  to  the 
declare  section  to  indicate  that  variables  op, 
file,  ok,  alarm,  state,  and  function  check!)  are  pri¬ 
vate  to  detector  and  cannot  be  accessed  by  the 
jammer. 

To  define  our  checksum  array  ok,  we  use  the 
well-known  notation  for  updates  to  data  struc¬ 
tures,  where  a  data  structure  like  an  array  is 
treated  as  a  function.  Thus  (f;  i :  u)  is  an  array 
whose  /th  element  is  u,  with  all  other  elements 
the  same  as  the  corresponding  elements  of  f.  By 
applying  the  script  arrays  op  and  file,  k  times  to 
file  system  f,  we  get 

ak  =((... ((f;  m 0] :  op[0](/M0]));  fflefl] : 

op[ l](f7/e[  1])); . . .  fit e[/c] :  op[k](file{k])) 

This  is  the  authentic  value  of  our  filesystem,  af¬ 
ter  k  steps  of  the  detector's  script.  This  allows  us 
to  say 

ok[k]  =check[ak) 

So  after  each  command  to  the  word  processor,  we 
compare  the  check  of  our  current  file  system  f  to 
the  precomputed  check  value  that  f  should  have. 
Our  program  ddiector  should  set  alarm  to  true  if 
any  check  of  the  file  system  failsto  return  the 
precomputed  value  stored  in  array  ok. 

To  guard  against  counterdetection  of  the  fixed 
script  cycle,  we  can  interleave  arbitrary  don’t- 
care  operations  that  are  either  compensatable  or 
undoable.  For  example,  between  script  operation 
op[i]  and  cp[/+l]  we  could  have  the  detector  sub¬ 
mit  don't-cardiO ]  . . .  don t-cardk]  followed  by  un- 
do[k] . . .  undd 0],  such  that  the  value  of  f 
following  undo[ 0]  isthe  proper  valuefor  cp[/+l], 
that  is  a1 .  The  significance  of  the  don’t-care  oper¬ 
ations  is  that  we  don’t  check  them  and  thus  don’t 
care  what  val  ues  they  produce,  as  long  as  we  can 
undo  or  compensate  them  away  before  running  a 
checked  operation  and  we  can  have  different 
don’t  care  operations  each  ti  me  we  chose  to  i  n- 
ter leave  them. 

We  want  to  prove  that  our  defense  will  detect  the 
jammer.  The  the  condition  we  want  to  prove  is  f 
astate  A  /n=EM  PTY  leads  to  alarm^true.  The 
operator  p  leads  to  q  means  that  once  p  becomes 
trueq  is  or  will  become  true.  The  proof  is  quite 


simple.  The  precondition  of  the  leads-to  makes 
program  wj  a  skip  statement.  Then  we  can  show 
that  program  detector  makes  the  alarm  true,  as 
long  as  we  can  demonstrate  that  f  ±  astate  im¬ 
plies  that  check(f)^ok[state].  That  implication 
follows  from  the  definition  of  ok[state],  (For  the 
reader  familiar  with  Unity,  proving  stable 
alarm  is  also  simple,  and  shows  that  the  alarm 
latches.) 

4.  Conclusions 

Storage  jamming  is  a  new  security  problem.  Un¬ 
like  confidentiality,  information  flow  is  not  a  cen¬ 
tral  issue.  Fraud  may  also  be  viewed  as  a 
problem  of  unauthorized  flow  of  assets  with  the 
perpetrator  being  concerned  with  maintaining 
the  i  ntegrity  of  the  assets  as  they  flow  the  wrong 
way.  I  n  the  case  of  storage  jamming,  flows  are  of 
lesser  importance  because  information  is  being 
destroyed  at  its  source.  Unlikedenial  of  service, 
wherethereis  littleconcern  with  avoiding  detec¬ 
tion,  storage  jamming  generally  only  makes 
sense  if  it  is  not  detected.  So  storage  jamming 
lies  between  the  boundaries  of  fraud,  unautho¬ 
rized  leakage,  and  denial  of  service.  It  is  a  threat 
to  complicated  mission-critical  systems  where 
jammers  can  easily  hide.  We  believe  it  is  possible 
to  provide  reasonable  protection  against  such  at¬ 
tacks. 

4.1.  Meeting  the  Modeling  Criteria 

The  Unity  paradigm  allows  us  to  construct  mod¬ 
els  of  jamming  in  which  the  architectural  fea¬ 
tures  are  limited  to  only  data  objects  and  data 
flows,  the  most  critical  aspect  of  storage  jam¬ 
ming.  The  proof  rules  and  the  proof  steps  are 
based  on  data  objects  and  data  flows,  so  the  rea- 
soning  is  relatively  close  to  our  intuitive  view  of 
thejamming  problem. 

We  have  shown  that  reasoning  about  the  actions 
of  our  example  jammer  and  proposed  defense  is 
natural;  assignment  to  variables  lets  us  reason 
about  jamming  and  detection  when  and  where  it 
happens  in  a  system.  We  also  showed  how  we 
can  make  simple  probability  statements  about 
these  examples.  The  probability  statements  are 
useful  in  modeling  jammer  rate  and  extent  char¬ 
acteristics.  Extending  these  probability  state¬ 
ments  to  model  susceptibility  as  bit,  field,  or 
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record  error  rates  is  relatively  easy.  We  expect  to 
be  able  to  extend  our  present  model  to  reason 
about  query  error  rates.  Because  we  use  assign¬ 
ments,  it  is  easy  to  model  persistence  of  values 
stored  in  specific  data  objects.  Likewise,  model¬ 
ing  selection  of  targets  and  generation  of  bogus 
values  can  be  done  in  a  natural  way. 

F  rom  our  perspective,  one  of  the  nicest  features 
of  the  Unity  paradigm  is  the  unbounded  fair  in- 
terleavi  ng  of  the  scheduler.  This  emphasizes  any 
synchronization  aspects  of  a  jamming  problem. 
This  is  particularly  interesting  for  building  sim¬ 
ple  high-level  models  of  real  systems,  to  analyze 
their  vulnerability  and  the  effectiveness  of  pro¬ 
spective  defenses.  Both  the  jammer  and  the  de¬ 
fense  will  probably  be  limited  in  the  protocols 
and  interprocess  communication  primitives  they 
use  to  synchronize  their  actions  with  other  pro¬ 
grams. 

We  have  yet  to  i  nvestigate  the  i  impact  of  security 
attributes  on  our  model.  Many  effective  attacks 
do  not  need  to  cross  access  control  boundaries; 
this  can  be  devastating  in  production  informa¬ 
tion  systems  where  sharing  and  interoperation 
are  mission  critical  requirements.  Flowever,  we 
need  to  understand  what  kind  of  attacks  might 
be  able  to  cross  access  control  boundaries. 

Our  proof  sketches  showed  us  that  a  quarantine 
subsystem  detection  object  defense  would  benefit 
from  a  script  that  has  two  characteristics:  1)  new 
values  for  the  target  data  objects  of  each  script 
operation  are  unique  and  2)  script  operations  ap¬ 
plied  to  rewritten  values  do  not  result  in  an  au¬ 
thentic  file  system  state.  These  characteristics 
keep  the  detector  from  skipping  over  a  specific 
jamming  attack  because  the  attack  accidentally 
wrote  a  correct  value  or  a  script-generated  up¬ 
date  accidentally  corrected  a  bogus  value. 

4.2.  Future  Extensions 

We  would  I  ike  to  be  able  to  model  the  complex 
data  structures  and  operations  found  in  practi¬ 
cal  systems.  To  do  this,  we  plan  to  extend  the 
Unity  model  in  two  ways:  by  adding  an  explicit 
data  model  and  by  incorporating  well-defined 
high-level  functions  on  the  right-hand  sides  of 
assignments. 


Our  first  extension  adds  a  set-and-tu pie  con¬ 
structor  data  model  for  describing  complex  stor¬ 
age  structures.  We  start  with  a  set  of  base  data 
objects ;  we  plan  to  use  the  fundamental  types 
char,  int,  and  float.  F  rom  the  base  objects  we 
plan  to  construct  complex  objects  from  sets  and 
tuples. 

We  have  already  used  our  second  extension  in 
the  example  jammer  and  in  the  detection  pro¬ 
gram.  Our  second  extension  allows  us  to  have 
abstract  operations  on  the  complex  data  struc¬ 
tures  introduced  by  the  first  extension.  We  plan 
to  enrich  the  assignment  semantics  by  allowing 
more  powerful  expressions  to  appear  on  the 
right.  To  model  low-level  operations  that  might 
be  used  for  jamming,  we  include  bitwise  opera¬ 
tions  (e.g.  left  shift  «,  exclusive-or  ©).  The 
problem  with  allowing  the  high-level  operators 
is  that,  in  the  unbounded  nondetermini  Stic  itera¬ 
tive  approach,  we  must  assume  termination  of 
programs  that  compute  the  val  ue  of  an  expres¬ 
sion  that  uses  the  high-level  operators.  This  is 
not  a  serious  problem  because  we  are  not  inter¬ 
ested  in  the  possible  effects  of  jamming  in  the 
presence  of  nonterminating  operators. 
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